arm: Add missing hflag update after writing xpsr #2268
Conversation
The previously used UC_MODE_MCLASS causes UC_CPU_ARM_CORTEX_M33 to be used. This CPU features ARM_FEATURE_M_SECURITY for which handler mode checks are skipped upopn exception return. This reveals a previously undetected issue.
Modifying xpsr might change processor state, after which the cached TBFLAGS need to be rebuild.
wuetj
force-pushed
the
fix/arm/xpsr_hflag_update
branch
from
aae4eae to
565aba0
Compare
| uc_common_setup(&uc, UC_ARCH_ARM, UC_MODE_THUMB | UC_MODE_MCLASS, code, | ||
| sizeof(code) - 1, UC_CPU_ARM_CORTEX_A15); | ||
| uc_common_setup(&uc, UC_ARCH_ARM, UC_MODE_THUMB, code, | ||
| sizeof(code) - 1, UC_CPU_ARM_CORTEX_M7); |
There was a problem hiding this comment.
Can you create a second test instead changing the used CPU? Maybe add a CPU parameter to the function and write two tests simply calling test_arm_m_exc_return.
There was a problem hiding this comment.
I'm not sure why UC_CPU_ARM_CORTEX_A15 is being used here since it's not an M-class CPU. UC_MODE_MCLASS overwrites the cpu model with UC_CPU_ARM_CORTEX_M33, so this value is ignored anyways.
I could create two separate test cases for UC_CPU_ARM_CORTEX_M33 (with M security feature) and UC_CPU_ARM_CORTEX_M4 (no M security feature) if necessary.
There was a problem hiding this comment.
This are two different code path so we should have two tests. One for M33 and one for this bug.
There was a problem hiding this comment.
The check for EXC_RETURN is simply always true if the CPU has security extension, since in that case the EXC_RETURN code can also be triggered in thread mode.
unicorn/qemu/target/arm/translate.c
Lines 807 to 811 in c24c9eb
If
EXC_RETURN works for the M7, it will always work for the M33.
I can add tests for both the M7 and M33 though, if you think it's necessary.
2 participants
This adds a missing hflag update after updating the xpsr.
Currently when using an Arm Cortex-M CPU, which does not feature
ARM_FEATURE_M_SECURITY, theEXC_RETURNinterrupt is not triggered.After some debugging it turns out the
v7m_handler_modecondition here is never true:unicorn/qemu/target/arm/translate.c
Lines 827 to 830 in c24c9eb
v7m_handler_modeis evaluated based on theHANDLERflag which is set when rebuilding hflags:unicorn/qemu/target/arm/helper.c
Lines 11592 to 11594 in c24c9eb
Since setting IPSR using
uc_reg_writedoes not rebuild hflags, qemu doesn't realize that it's currently in an exception and returning from an exception causes a hard fault.This fixes this by rebuilding hflags after updating xPSR.
This doesn't matter for processors with the security feature since the condition is always true in that case. I've updated the test to catch this.